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Abstract. The Hoare approach to program verification relies on the construction 
and discharge of verification conditions (VCs) but offers no support to trace, ana- 
lyze, and understand the YCs themselves. We describe a systematic extension of 
— theT5oare-mles-by-labels-so4hat-fiie-calculus-itself-can-be-used4o--build-up^rp/a=-- 
nations of the VCs. The labels are maintained through the different processing 
steps and rendered as natural language explanations. The explanations can easily 
be customized and can capture different aspects of the VCs; here, we focus on 
their structure and purpose. The approach is fully declarative and the generated 
explanations are based only on an analysis of the labels rather than directly on 
the logical meaning of the underlying VCs or their proofs. 

Keywords: program verification, Hoare calculus, traceability. 

1 Introduction 

Program verification, is easy when everything is correct and automated tools do all the 
work: a verification condition generator (VCG) then takes a program that is annotated 
with “logical mark-up” (i.e., pre-/post-conditions and invariants) and produces a num- 
ber of verification conditions (VCs) that are simplified, augmented with a domain the- 
ory, and finally discharged by an automated theorem prover (ATP). In practice, however, 
many things can — and typically do — -go wrong: the program may be incorrect or un- 
safe, the annotations may be incorrect or incomplete, the simplifier may be too weak 
or counter-productive, the domain theory may be incomplete, and the ATP may run out 
of resources. In each of these cases, users are confronted only with failed VCs (i.e., 
the failure to prove them automatically), but typically receive no additional information 
about the causes of the failure. They must thus analyze the VCs by interpreting their 
constituent parts, and relating them through the applied Hoare rules and simplifications 
to the corresponding source code locations. Unfortunately, VCs are a very detailed and 
low-level representation of both the underlying information and the process used to 
derive it, so this is often difficult to achieve. 

Here we describe an implemented technique that helps users to trace, analyze, and 
understand VCs. Our idea is to systematically extend the Hoare rules by “semantic 
mark-up” so that we can use the calculus itself to build up explanations of the VCs. This 
mark-up takes the form of semantic labels that are attached to the meta-variables used in 
the Hoare rules, so that the VCG then produces labeled versions of the VCs, The labels 
are maintained through the different processing steps, in particular the simplification, 
and are then extracted from the final VCs and rendered as natural language explanations. 



Most verification systems based on Hoare logic offer some basic tracing support 
by emitting the current line number whenever a VC is constructed. However, this does 
not provide any information as to which other parts of the program have contributed 
to the VC, how it has been constructed, or what its purpose is, and is therefore insuffi- 
cient as' a basis for informative explanations. Some systems produce short captions for 
each VC (e.g., JACK [1] or PerfectDeveioper [2]). Other techniques focus on a detailed 
linking between source locations and VCs to support program debugging [10,11]. Our 
approach, in contrast, serves as a customizable basis to explain different aspects of VCs. 
In this paper, we focus on explaining the structure (including source location informa- 
tion) and the purpose of VCs, helping users to understand what a VC means. 

In our approach we only explain what has been explicitly declared to be signifi- 
cant using labels. Hence, the generated explanations are based only on an analysis of 
the labels but not of the structure or even logical meaning of the underlying VCs. For 
^example^wejwouldmotJrv to infe r that two formulas are the base and step case of a n ..in- 
duction unless the formulas axe specifically marked up with this information. This also 
lets us use a syntax-directed style for the labeling and to restrict the rendering to a local 
rather than a whole-program analysis; consequently, rendering is compositional and can 
be implemented using simple text templates. Finally, we restrict ourselves to explain- 
ing the construction of VCs (which is the essence of the Hoare approach) rather than 
their simplification and proof. Hence, we maintain, but do not introduce, labels dur- 
ing simplification, and strip them off before proving the VCs; existing techniques [8] 
could be applied to explain the detailed proofs, although it is unlikely that this would 
provide much additional insight since the key information is already expressed in the 
annotations and consequently in the VCs as well. 

We developed our technique to support a certifiable code generation approach, 
where the generator provides Hoare-style safety proofs for the generated code. Here, 
human-readable explanations of the VCs are particularly important to gain confidence 
into the large and complex system. However, our technique is not tied to code genera- 
tion or safety certification and can be used in any Hoare-style verification context. 

In the next section, we briefly recall the necessary logical background; for details see 
[3, 4, 15]. In Section 3, we extend the basic calculus to provide structural explanations, 
and then describe our implementation. Section 5 extends the approach further to explain 
the purpose of VCs in more detail. Finally, Sections 6 and 7 compare related work and 
outline current and future work. 


2 Logical Background 

2.1 Hoare Logic and Program Verification 

We follow the usual Hoare-style program verification approach (see [12] for more de- 
tails), in which the verification problem is solved in two separate stages. In the first 
stage, a VCG applies the proof rules of the underlying Hoare calculus to the annotated 
program to produce a number of VCs. In the second stage, an ATP discharges the VCs. 
The main advantage of this two-stage approach is that it splits the decidable (given suit- 
able annotations) construction of the VCs from their undecidable discharge. The main 
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disadvantage, however, is that the VCs become removed from the program context, 
which exacerbates the understanding problem. 

Figure 1 shows the Hoaxe rules that are implemented by our VCG. They are formal- 
ized using the usual Hoare triples P {c} Q, i.e., if the condition P holds and the com- 
mand c terminates, then Q holds afterwards. The update - rule uses McCarthy’s select- 
and update-functions to handle array updates. For the completeness of the calculus, we 
also need the usual rule of consequence but since the VCG itself never applies it, we 
can ignore it here. 

We restrict our attention to an imperative core language which is sufficient for 
the programs generated by NASA’s certifiable code generators AutoBayes [9] and 
AUTOFlLTER [16]. Extensions to other language constructs are straightforward, as long 
as the appropriate (unlabeled) Hoare rules have been formulated. 


2.2 Source-Level Safety Certification 

The purpose of safety certification is to demonstrate that a program does not violate 
certain conditions during its execution. A safety property is an exact characterization of 
these conditions based on the operational semantics of the language. A safety policy is 
a set of Hoare rules designed to show that safe programs satisfy the safety property of 
interest. Most approaches to safety certification, in particular proof-carrying code [13], 
operate on object code but since our goal is to explain VCs in relation to the original 
program, we follow a source-level approach. From this perspective, the important aspect 
of safety certification is that the formulas in the rules have moreintemal structure. This 
can be exploited by our approach to produce more detailed explanations. 

For each notion of safety which is of interest a safety property and the correspond- 
ing safety policy must be formulated. This is usually straightforward; in particular, a 
safety policy can be constructed systematically by instantiating a generic rule set that 
is derived from the standard rules of the Hoare calculus [3]. The basic idea is to extend 
the standard environment of program variables with a “shadow” environment of safety 
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variables which record safety information related to the corresponding program vari- 
ables. The rules are then responsible for maintaining this environment and producing 
the appropriate safety obligations. This can be achieved genetically using a family of 
safety substitutions that are added to the normal substitutions, and a family of safety 
predicates that are added to the calculated weakest preconditions (WPCs). Safety cer- 
tification then starts with the postcondition true and computes the weakest safety pre- 
condition (WSPC), i.e., the WPC together with all applied safety predicates and safety 
substitutions. If the program is safe then the WSPC will be provable without any as- 
sumptions, i.e., true {c} true is derivable. 

Figure 2 shows the modified rules for the initialization safety policy. This ensures 
that each variable or individual array element has been explicitly assigned a value before 
it is used. The safety environment consists of shadow variables x inil that contain the 
value init after the variable, x, has been assigned a value. Arrays are represented by 
shadow arrays to capture the status of the individual elements. All statements accessing 
lvars affect the value of a shadow variable (cf. the assign update -, and jfor-rules). 
However, all rules also need to produce the appropriate safety predicates safe mit (e) for 
all immediate subexpressions e of the statements. Since the safety property defines 
an expression to be safe if all corresponding shadow variables have the value init, 
safe iJlh (x [i] ) for example simply translates to ~ init A sel(: r iak , i) = init. 

2.3 Annotations 

A certifiable code generator [4, 15] derives not only code from high-level specifications 
but also the detailed annotations required to certify a. given safety property. The basic 
idea is to make the annotations part of the templates used in the generator so that they 
can be. instantiated and refined in parallel with the code fragments. The annotations 
focus on locally relevant information, without describing all the global information that 
may later be necessary for the proofs. It. then relies on a separate annotation propagation 
phase after the code has been constructed. 

The propagation algorithm can be seen as a crude approximation of a strongest 
postcondition predicate transformer. It pushes the generated local annotations forward 
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(c) Code with actual annotations. 

along the edges of the syntax tree as long as the information can be guaranteed to remain 
unchanged. The VCG then processes the code after propagation. The calculus assumes 
that all loops have an invariant; typically, they consist mainly of assertions which have 
been propagated from earlier in the program. 

For us, human-readable explanations of the VCs are important in gaining confidence 
into the (large and complex) generator, the propagator, and the certifier. However, our 
approach is not tied to code generation; we only use the generator as a convenient 
source of the annotations that allow the construction of the VCs and thus the Hoare-style 
proofs. Moreover, even though there is no need to manually classify annotations (since 
all work can be done by the VCG), it is possible to add domain-specific information in 
the form of additional labels which are then processed in the usual way (cf. Section 5). 

3 Explaining the Structure of VCs 

The main aspect of VCs that we consider in this paper is their structure. Since VCs 
have the form Hi A . . . A H n => C after simplification, the structure is based on the 
top-level dichotomy between logical hypotheses and conclusions. However, for mean- 
ingful explanations we need a more detailed characterization of the sub-formulas. This 
information cannot be recovered from the obligations or the code but must be specified 
explicitly. A key insight of our approach is that the different sub-formulas stem from 
specific positions in the Hoare rules, and that the VCG can thus add the appropriate 
labels to the VCs. Note that locations alone are not even sufficient to distinguish be- 
tween hypotheses and conclusions; due to backward edges in the control flow graph, 
the highest line number does not necessarily refer to the conclusion. 

3.1 Example Explanations 

Figure 3 shows three different versions of a small example program to illustrate the pro- 
cess. In Figure 3(a) and 3(b), the actual annotations are abstracted by meta-variables to 



The purpose of this proof obligation is to show that the loop invariant at line 9 under the 
substitution originating from line 10 is still true after each loop iteration; it is also used to 
show the preservation of the loop invariant at line 9. Hence, given 

- the postcondition at line 3 propagated into the invariant at line 9, 

- the postcondition at line 5 propagated into the invariant at line 9, 

- the postcondition at line 7 propagated into the invariant at line 9, 

- the invariant at line 9, 

- the loop bounds at line 10, 

show that the loop invariant at line 9 under the substitution originating from line 1 1 is still 
true after each iteration to line 11. 

Fig. 4. Explanation automatically generated for the VC 0 < i < 2 A — IN IT A y taix == 
INIT A Zi ni i = IN IT INIT = INIT derived from Figure 3(c). 


.simplif y the presentation. Figure 3(a) shows the original annotations while Figure 3(b) 
shows the result of the propagation phase. Note that this step already introduces some 
labels; for example, in line 7 the sub-formulas Pi and P 2 are labeled with their orig- 
inal locations (i.e., lines 3 and 5). Throughout the paper we use the notation r t llab to 
denote a term t that is labeled with a label lab; the labels can also have internal structure 
(see Section 3.2 for details). Figure 3(c) shows the actual annotations required (before 
propagation) to certify the program as initialization safe. 

The version in Figure 3(b) induces simple VCs whose structure still directly reflects 
their intended meaning. Each sub-formula is preserved and can be traced back to its ori- 
gin, which allows a human to interpret them in text, e.g., (t?) Pi A P 2 A P 3 A I (i) A 0 < 
i < 2 corresponds to “Given the postcondition Pi from line 3, the postcondition P 2 
from line 5, and the postcondition P 3 from line 7, the loop bounds at line 8 , and the 
loop invariant at line 9, show that the loop invariant at line 9 hold is still true after 
each loop iterationTThe explanations become more complicated when the substitutions 
arising from the assign ~ and update- rules are taken into account because the non-local 
effects of substitution applications need explaining: the sub-formulas are no longer pre- 
served intact and need to be traced to their different origins and for larger programs, the 
overall structure quickly becomes complex. Our technique thus mechanizes the textual 
interpretation, and Figure 4 shows the automatically generated structural explanation 
for the same VC as above, but now derived using the full annotations in Figure 3(c ). 1 

3.2 Mark-Up Structures 

Concept Hierarchy The basic information for explanation generation is the set of 
underlying concepts and their hierarchical relations. This hierarchy depends of course 
on the particular aspect of the VCs to be explained. In the case of the structural ex- 
planations, the concepts characterize either the origin or the purpose of a sub-formula. 
Figure 5 shows the concept hierarchy; the actual labels are shown in parentheses next 
to the corresponding concepts. 

1 Of course, aggressive simplification reduces the complexity of the VCs (and even reduces 
away the given example) but this does not solve the problem in general, and one could argue 
that it in fact compounds the problem by changing the formula structure. 
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Fig. 5. Concept hierarchy for structural explanations 


Propositions are either hypotheses or conclusions, reflecting their eventual position 
in the VC. Hypotheses are further divided into assertions and control flow predicates. 
Assertions refer to sub-formulas that occur as annotations in the program, either origi- 
nally or after propagation (Le., pre- and post-conditions and loop invariants). Since the 
(f<?r)-rule uses the loop invariant as hypothesis in two different contexts, we distinguish 
the two concepts Oass-tnv r.iassjnv_exrt Control flow predicates refer to sub-formulas 
that reflect the program’s control flow. For both if- statements and while-loops, the con- 
trol flow predicates occurring in the program are required by the rules in both their 
original and negated forms, so that we get four different concepts for explanations. For 
for-loops, the control flow predicate does not directly occur in the program but is de- 
rived from the given loop bounds. 

Conclusions capture the primary purpose of a VC. For general verification, the dif- 
ferent types of conclusions are given by the types of assertions, as each assertion has to 
be established (Le., shown valid at its location). As in the case of the hypotheses, loop 
invariants are used in two different forms, the entry form (or base case) r * l estjnv and the 
step form f d esUnvJte h ; Note that an assertion can be used both as hypothesis and as con- 
clusion, even in the same VC. Our approach allows the explanations to distinguish these 
two bits of information from the same source. For safety verification, we additionally 
have the safety conditions f - lsafety that have to be demonstrated. 



Qualifications , which apply to both hypotheses and conclusions, further character- 
ize the origin of a sub- formula. The different substitution concepts reflect the substitu- 
tions of the underlying Hoare calculus. Both assignment concepts capture the origin and 
effect of assignments on the form of the resulting VCs.For safety verification, we addi- 
tionally get safety substitutions , again for the scalar (f.isub_safety) and array (t.iupd-safety) 
cases. Origin labels ( r -l° n 9(0) denote formulas that result from annotations that have 
been propagated from their original location; this location is the additional argument of 
the label. They are specific to the way the code generator produces the annotations. 

Contributions capture the secondary purpose of a VC; this arises when a recursive 
call to the VCG produces VCs that are conceptually connected to the purpose of the 
larger structure. In general, contributions arise for nested program structures which re- 
sult in “nested” VCs (e.g„ loops within loops). For example, all VCs emerging from the 
premise P {c} I of the while- rule (cf. Figure 2) contribute to showing the preservation 
jofrthe inva riant I over the loop body c, in dependent of their prim ary purpose. For the 
structural hierarchy, this preservation of invariants ( r - 1presjnv ) is the only contribution 
concept: 

Concept Classes In the concept hierarchy shown in Figure 5, only the minimal (i.e., 
leaf) concepts are associated with labels. However, the other concepts also capture im- 
portant domain information, as they group together related labels. These concept classes 
are then used as filter predicates by the rendering phase (cf. Section 4.2) and also to 
show the consistency of the rule mark-up. 

For the structural explanations, the important concept classes are the two proposi- 
tion classes hypothesis and conclusion , the two qualification classes substitution and 
origin , and the contribution concept. 

Label Structure The labels that are actually attached to the VCs are ground terms 
over the label functors £ shown in Figure 5. Each label c(o } n) thus comprises a con- 
cept c € £ which describes the role the labeled term plays, the location o where it 
originated, and an optional list of nested labels n. The concept of the outermost label 
generally determines how the underlying term is rendered. Locations refer either to an 
individual position or to a range; in our implementation, we use plain line numbers for 
locations and ranges; to capture more details, we could instead use full term positions 
N* without any substantial changes. The nested label list initially holds the qualifica- 
tions for the concept of the top-level formula. After normalization and extraction, just 
before rendering, it also contains, labels extracted from sub-formulas. 

3.3 Rules 

In general, it is not sufficient to just output explanations as the VCs are constructed. In- 
stead, the VCG must add the right labels at the right positions; it must also pass maric-up 
back through the program by attaching it to the WSPC, so that information from one 
point in the program can be used at any other point. Modified Hoare rules concisely 
capture the semantic mark-up (i.e., label types and positions) required for any given ex- 
planation aspect. Labels can be added in three places: to the “incoming” postcondition 
of a recursive VCG call in the premise of an inference rule, to the WSPC, or to a gen- 
erated VC. Figure 6 shows the rules for the initialization safety policy marked-up for 
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Fig. 6. Hoare rules for initialization safety with semantic markup 


explaining the structural aspect of VCs ; those rules not shown do not require any mark- 
up. The rules derive the usual triples, P {c} Q, but now all elements can be labeled. 
For clarity, we omit the location information in the rule formulation but assume that the 
VCG obtains it from the statements and annotations and appropriately incorporates it 
into the labels. Note that the incoming postconditions have no location information by 
themselves, although their sub-formulas do. ■ 

The assign - and update-rules only require mark-up in the WSPC. The safety pred- 
icate can be a complex sub-formula, depending on the property to be certified and 
the structure of the expression(s), but the mark-up is not dependent on the specific 
safety property — all we need to know for an explanation is that this is in fact the safety 
predicate. However, it could contain additional embedded labels for more detailed or 
property-specific explanations. The substitutions need mark-up to record their type and 
the origin of the substituted expressions, Note that by labeling only the expressions and 
not the variables we can use the normal substitution mechanisms. 

The if - rule is also fairly simple. The safety predicate is labeled as above. The other 
two parts of the WSPC reflect the two branches of the /-statement They are-guarded 
by the appropriate version of 6, and the labels just record which version has been used. 
Note that P* and P 2 are likely to be labeled, depending on the safety policy and the 
particular structure of the branches Ci and c 2 , but no additional labels are required for 
them in the context of the //-statement. 

The loop rules are more complicated; we focus on the while-rule but the for-rule 
has the same overall structure. The WSPC comprises the safety predicate, which is la- 
beled as before, and the invariant, which has to be established in the entry form and 
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is thus labeled with r * l estJnv . In the premise, individual sub-formulas of both the exit- 
condition I A -ib => Q and the step-condition I A b => P are labeled appropriately; 
in addition, the entire step-condition is labeled with its secondary purpose, namely to 
contribute to showing the preservation of the invariant. In the triple P {c} 7, the incom- 
ing postcondition I must be labeled with its purpose for the recursive call; moreover, 
all emerging VCs must be marked up with the secondary purpose f * lpresJnv . We indicate 
this by labeling the entire triple. Note how the same formula I is used in four differ- 
ent roles and consequently labeled in four different ways. This contextual knowledge 
is only available at the point of rule application and can not be easily recovered by a 
post-hoc analysis of the generated VCs. This is a strength of our approach. 

Finally, the asseri-ru.lt is straightforward to mark up. The asserted pre- and post- 
conditions are labeled according to their use either as hypotheses (in the VCs) or as 
conclusions (in the WSPC and recursion). 
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3.4 Explanation Templates 

Finally, we also need to define the underlying abstract syntax and actual textual repre- 
sentation of the explanations. Figure 7 shows parts of the BNF-grammar that specifies 
both. It is derived from the concept hierarchy: the leaf concepts (Le., labels) double as 
non-terminals, and the concept classes correspond to alternative productions. 

Since the purpose of the grammar is to generate rather than analyze text, the right- 
hand sides of the rules can be interpreted as functions of type Label list -^Text option. 
These explanation templates are similar to C’s format strings and can also contain spe- 
cial operators, which control parameter passing into other non-literals. The %-operator 
allows access to the incoming parameters, using a position notation so that %1 is the 
first parameter and %1.1 its first argument. The $-operator tests an argument against 
a pattern, so that for example SubstBlock%L2$Substitution takes the second argument 
of the incoming label (i.e., the nested labels), filters out those that match the pattern 
Substitution (i.e., are concepts in that class) and passes the result on. 
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Fig. 8. Labeled rewrite rules 


^he-templates~aiIow-an-easy--eustomization-and-fine---grained-contoLof-the-tex-taaI- 
explanations. For example, we render origins in hypotheses differently than in conclu- 
sions (cf. OriginL and OriginR in Figure 7). 

4 Explanation Generation 

The generation of the actual textual explanations is independent of the particular aspect 
which is to be explained and can thus be reused. It proceeds in two phases, a rewrite- 
based normalization of the VCs and corresponding labels followed by a rendering phase 
that extracts and further normalizes the final label structure and, using the specific ex- 
planation templates, turns it into natural language text 

4.1 Labeled Rewriting 

The VCs (whether labeled or unlabeled) become quite complex and need to be simpli- 
fied aggressively before they can be submitted to an ATP with any hope of success (cf. 
[6] for experimental evidence). In the unlabeled case, the simplification can easily be 
implemented by a term rewriting system. Unfortunately, the unlabeled rules cannot be 
reused “as is” for the labeled case because (!) the labeling changes the term structure 
and thus the applicability of the rules and (u) the labels need careful handling — on the 
one hand, they cannot simply be distributed over all operators because this can destroy 
their proper scope, while on the other, they cannot just be pushed to the top of the VC 
because this would result in redundant and imprecise explanations. 

Figure 8 shows the labeled rewrite rules that are used together with additional unla- 
beled. rules to simplify the labeled VCs. Their formulation uses the auxiliary functions 
| • | to remove labels from terms, and [■] to extract the labels of a term. [•] is defined by 

[ r /(ii, . . , t„)’ lab ] = lab <g> fltij © . ..© [y ) 

= pi] © ... © [f n J 

where 0 is list concatenation and the label composition operator appends the inner 
labels ! to the list of labels nested in the outer label c(o,n), he., c(o,n)®Z = c(o,n0 Z). 



The rules are based on the assumption that the majority of the VCs can be rewritten 
to true. Their purpose is thus (i) to remove redundant labels, (ii) to minimize the scope 
of the remaining labels, and (in) to keep enough labels to explain any unexpected fail- 
ures. The rules fall into five different categories. The first category removes labels from 
trivially true (sub-) formulas because these require no explanations. The next category 
selectively removes labels from trivially false sub-formulas so that the equivalent unla- 
beled versions can apply and eliminate the sub-formulas. The remaining context then 
provides the information for the explanations. However, the labels obviously need to 
be retained if the unlabeled versions rewrite the entire formula into false, since there 
is no remaining context to explain the failure. Note that the second rule only extracts 
the labels from the two contradictory literals but does not introduce additional mark-up 
to explain the contradiction. The rules in the fourth distribute labels over conjunction 
and (nested) implication, respectively, so that the label scopes are minimized in the fi- 
nal simpl ified VCs. The final category encodes know ledge about how the labels will 
be interpreted in the underlying domain. For example, the second rule flattens nested" 
labels using the label composition operator, thus enabling other labeled and unlabeled 
rules to apply. The last rule specifies the effect of selecting into an updated array. In 
order to explain the resulting term we need to know that the disappearing upd-fnnctor 
is conceptually reflected in the guard and the success-branch of the conditional, but not 
in the failure-branch, and that the label must thus be attached to these two only. 

The rewrite system is not confluent modulo labels, in the sense that terms such as 
false 1 * A “i false ]m can be rewritten into differently labeled normal forms (in this case 
false 1 ', false 1 ™ (using commutativity of A), and false 1 ^). However, the system is 
confluent after label stripping | ■ |, and since the rules are labeled versions of rules in 
the underlying unlabeled rewrite system, labeling does not interfere with the underlying 
unlabeled normalization. 


4.2 Rendering 


The core rendering routine, which turns the (labeled) VCs into human-readable text, is 
independent of the actual aspect that is explained. It relies on the building blocks de- 
scribed so far and comprises four steps: (i) VC normalization, using the labeled rewrite 
system; (ii) label extraction, using f - J; (Hi) label normalization, to fit explanation tem- 
plates; (iv) text generation, using the explanation templates. 

The third step flattens nested substitution- and contribution-labels, so that for ex- 
ample sub(p, sub(g, sub(r))) is rewritten into ' the list s(ub(r>}v It also 

merges back together conclusions from the same line which have been split over differ- 
ent literals during the first step. This is realized by an additional rewrite system (omitted 
here) that is defined together with the explanation templates. 

The Tenderer contains code to interpret the BNF meta-symbols (i.e., lists and al- 
ternatives) as well as some glue code (e.g., sorting label lists by line numbers) that is 
spliced in to support the text generation. It also provides default templates for concepts 
that are useful for different explanation aspects, for example lines and ranges. 



var i, j ,x,m[0 : 9] ; 
i : =0 ; X : =0 ; 
while i< 1 00 

inv i > 0 Vfc • (0 < k < 9 =$> se/(m inU , k) ~ INIT) do 
i : = i + l ; 
if i>0 then 
for j : = o to 9 

inv Vh - (0 < k< 9 => sel(m ia i , , /c) = INIT) do 
x : =x+m [ i ] ; 

else 

for j : = 0 to 9 

inv V& • (0<k<j — l ■=» sel(m iait7 k) == INIT) do 
m[i] ; — i ; 

post r Vfc • (0< fe<9 => sel(rn- mh , fc) •== INIT) linrt ^ 0:12,m ^ 

Fig. 9. Code with domain-specific label 

5 Explaining the Purpose of V Cs 

The explanations constructed by the rules in Figures 6 relate primarily to the structure 
of the VCs. However, this structural information also has some semantic information 
since it distinguishes the multiple roles a single annotation can take. We can go further 
and use domain-specific information to give a more semantic explanation of VCs which 
complements the purely structural logical view. 

For example, usually one code block initializes a variable while other parts of the 
program use it and so rely on its initialization. For safety certification, numerous VCs 
will be generated both within the definition of the variable and for each of its uses. 
However, the structural explanations do not relate any of the VCs to their role either as 
a constituent obligation within a definition for a given safety policy or when used later 
in another part of the program. We call this role (informally) the purpose of a VC. 

In order to reflect this, we need to explain the appropriate VCs in terms of establish- 
ing a definition, while all VCs produced within the definition block should be labeled as 
contributing to that definition, similar to the structural case of nested loops. Likewise, 
whenever the final postcondition is used as a hypothesis, e.g., to show the safety of a 
later use, it must be labeled as originating from the definition. 

Of course, the situation can quickly become complex. There might be irrelevant 
code within the the definition block, so that the VCs are not obviously tied to the struc- 
ture of the definition. Similarly, as shown in the example in Figure 9, the path from 
definition to use might he convoluted and via intermediate annotations. To deal with all 
this, we need to extend the structural explanations with definitional information. 

We do this with a simple extension to the existing calculus. The basic ideals to add 
labels to the formulas in the program’s annotations that express domain-specific refine- 
ments of the purely structural concepts shown in Figure 5. For example, in Figure 9 the 
postcondition Vi * 0 < i < 9 sel{m inin i) — init in line 13 is labeled with- 
1 0:12) to represent the fact that at this program point the array m is fully initialized, 
due to the statements in lines 10-12. Note that the fact that this code block represents 
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The purpose of this proof obligation is to establish the postcondition at line 13 (i.e., line 10 
to line 12 define the variable m); it is also used to show the definition at line 13, which in 
turn is used to show the preservation of the loop invariant at line 4. Hence, given 

- the guard at line 3, 

- the invariant at line 4, 

- the negation of the condition at line 6 under the substitution originating from line 5, 

- the invariant at line 1 1 in its exit form after line 12, 

show the postcondition at line 13 (i.e., line 10 to line 12 define the variable m). 

Fig. 10. Explanation automatically generated for the VC (i < 100 A i -b 1 < 1 A (i > 0 =4> 
( y/k * (0 < k < 9) sel{rriuii k) — INXt))) ((V/c - (0 < k < 9) => sel(m init3 k) = 1NIT) =>• 
(V/b • (0 < k < 9) => sel(m mhy k) — INIT)) derived from Figure 9. 


an initialization cannot be inferred by the VCG but must be specified externally, e.g., 
-b^the-code-generator-SQ-the-explanatiojis are still b ased on explicitly s pecified labels. 

Domain-specific labels are only introduced at annotations; we can restrict them even 
further to pre- and postconditions since the enclosed statements correspond to blocks 
with a logical structure which is reflected in the label and used in the explanation. 
Hence, we only need to introduce one additional rule 


fp/iass_pre(i) ^ [pi contrib(i) T p [q/i estpost(!)l contrib(I) 

(label) r -r-^/T nro./l\ r t-i/ , x-. 


that generalizes the assert- rule. The label-mle “plucks' 5 the label off the postcondition 
and passes it into the appropriate positions. Labels in positions that are already labeled 
by the assert-m\e need to be modified to take the domain-specific labels as an additional 
argument. For example, ass_post(iab) then refers to an asserted postcondition (i.e., a 
postcondition used as a hypothesis) for a lab-block. In addition, we also introduce a 
new contribution label contrib(lab), similar to the invariant preservation in the structural 
concept hierarchy. This is added to the WSPC recursively computed for the block, and 
to all YCs emerging during that process. These more refined labels let the renderer 
determine when a hypothesis is actually the postcondition of a domain-specific block, 
or when a VC is just a contributor to the block. Note that this modification does not 
affect the other rules of the calculus since the “backwards” formulation of the rules 
means that the labels plucked from the formulas will be silently passed through into 
the final VCs. It is the responsibility. of the renderer to make use of this additional 
information as it appears in the final labeled VCs. Figure 10 shows an example for this. 


6 Related Work 

Most VCGs link VCs to source locations, i.e., the actual position in the code where the 
respective rule was applied and hence where the VC originated. Usually, the systems 
only deal with line numbers but Fraer [10] describes a system that supports a “deep 
linking” to detailed term positions. JACK [1] and PeifectDeveloper [2] classify the VCs 
on the top-level and produce short captions like “precondition satisfied”, “return value 
satisfies specification”, etc. In general, however, none of these approaches maintain 
more non-local information (e.g., substitution applications). 



Denney and Venkatesan [7] present a system for generating safety documents. It 
also turns VCs into text in order to explain the safety of the code but differs from the 
current work by being more policy- and code-driven. It only uses the VCs which com- 
prise safety conditions, and combines rendering of the VCs with further code analysis 
do give a global explanation, whereas we concentrate on explaining all VCs directly. 

Leino et al [11] also have a system for explaining VCs. In particular, their expla- 
nations are of traces to safety conditions. This is sufficient for debugging programs, 
which is their main motivation. However, they only label the “counterexample context” 
whereas we label the entire VC and can also explain the more global purpose of a proof 
obligation. Both [11] and the current work are based on extending an underlying logic 
with labels to represent semantic explanatory information. However, they differ in how 
these labels are used by the verification architectures. Leino’ s system introduces the 
labels by first desugaring the language into a lower-level form. Labels are treated as 
uninterpreted predicate symbols and labeled formulas are therefore j ust ordinary formu- 
las. This labeled language is then processed by a standard VCG which is “label-blind”. 
In contrast, we do not have a desugaring stage, and use the VCG and propagator to in- 
sert the labels. Consequently, our simplifier needs to be label-aware, but since we strip 
labels off the final VCs after the explanation has been constructed, we do not suffer 
any performance problems with the ATP, nor do we place special requirements on the 
prover like they do. 

7 Conclusions and Future Work 

The explanation mechanism which we have described here has been successfully im- 
plemented and incorporated into our certification browser [5]. This tool is used to nav- 
igate the artifacts produced during certifiable code generation, and it uses the system 
described in this paper to successfully explain all the VCs produced by both AUTO- 
FlLTER and AutoBayes for all safety policies. 

We are currently redesigning the annotation generation mechanism for our code 
generators and the explanation mechanism has helped us debug several problems that 
arose there. In addition to its use in debugging, the explainer can also be used as a 
means of gaining assurance that the verification is itself trustworthy. This complements 
our previous work on proof checking [14]: there a machine checks one formal artifact 
(the proof), here we support human checking of another (the VCs). With this role in 
mind, we are currently extending the tool to be useful for code reviews. 

Much more work can be done to improve and extend the actual explanations them- 
selves. Similar to frame axioms, VCs often contain complex subformulas that remain 
unchanged because they are just pushed through parts of the program, and the current 
explanations do not explain that. Similarly, they do not make any use of the particular 
safety policy which is being certified but this could be used to give more informative 
explanations, particularly in combination with inductive steps. For example, for the ini- 
tialization safety which is used as an example in this paper we would like to generate 
phrases of the form “initialized up to i-V\ More generally, we would like to allow 
explanations to be based on entirely different explanation structures or ontologies. Our 
approach can, for example, also be used to explain the provenance of a VC (i.e., the 



tools and people involved in its construction) or to link it together with supporting in- 
formation such as code reviews, test suites, or off-line proofs. Moreover, although we 
have restricted our attention here to text generation, the underlying mechanisms are 
more general and could for example also be used to generate prover hints or even entire 
proof scripts for the VCs. The techniques could also be applied to other program logics, 
such as the refinement calculus. 

Finally, there are also interesting theoretical issues. The tenderer relies on the exis- 
tence of an Explanation Normal Form , which states intuitively that each VC is labeled 
with a unique conclusion. This is essentially a rudimentary soundness result, which can 
be shown in two steps, first by induction over the marked-up Hoare rules in Figure 6 
and then by induction over the labeled rewrite rules in Figure 8. We are currently devel- 
oping a theoretical basis for the explanation of VCs that is generic in the aspect that is 
explained, with appropriate notions of soundness and completeness. 

References 

1. L. Burdy and A. Requet. Jack: Java applet correctness kit In Proa 4th Gemplus Developer 
Conference , Singapore, Nov. 2002. 

2. D. Crocker. Perfect developer: a tool for object-oriented formal specification and refinement. 
In FM 2003 Tool Exhibition Notes, pp. 37-41, Pisa, Italy, 2003. 

3. E. Denney and B. Fischer. Correctness of source-level safety policies. In FM 2003, LNCS 
2805 , pp. 894-913. Springer, 2003. 

4. E. Denney and B. Fischer. Certifiable program generation. In GPCE 2005, LNCS 3676 , pp. 
1 7-28 . Springer, 2005 . 

5. E. Denney and B. Fischer. A program certification assistant based on fully automated the- 
orem provers. In Proa Inti Workshop on User Interfaces for Theorem Provers , (UITP’05), 
Edinburgh, 2005. 

6. E. Denney, B. Fischer, and J. Schumann. An empirical evaluation of automated theorem 
provers in software certification. Inti /. of AT Tools , 15(1): 8 1-107, 2006. 

7. E. Denney and R. P. Venkatesan. A generic software safety document generator. In 10th 
AMAST , LNCS 3097 , pp. 102-116. Springer, 2004. 

8. A. Fiedler. Natural Language Proof Explanation. In Mechnizing Mathematical Reasoning , 
LNAI 2605 , pp. 342-363. Springer, 2005. 

9. B. Fischer arid J. Schumann. AutoBayes: A system for generating data analysis programs 
from statistical models. J. Functional Programming , 13(3):483-508, 2003. 

10. R. Fraer. Tracing the origins of verification conditions. In 5th AMAST , LNCS 1101, pp. 
241-255. Springer, 1996. 

11. K. R. M. Leino, T. Millstein, and J. B. Saxe. Generating error traces from verification- 
condition counterexamples. Science of Computer Programming, 55(l-3):209-226, 2005. 

12. J. C. Mitchell. Foundations for Programming Languages. The MIT Press, 1996. 

13. G. C. Necula and P. Lee. The design and implementation of a certifying compiler. In 
PLDF98 , pp. 333-344. ACM Press, 1998. 

14. G. Sutcliffe, E. Denney, and B. Fischer. Practical proof checking for programcerrification. In 
Proc. CADE-20 Workshop on Empirically Successful Classical Automated Reasoning ( ES - 
CAR ’05), Tallinn, Estonia, July 2005. 

15. M. Whalen, J. Schumann, and B. Fischer. Synthesizing certified code. In FME’02, LNCS 
2391, pp. 43 1-450. Springer, 2002. 

16. J. Whittle and J. Schumann. Automating the implementation of Kalman filter algorithms. 
ACM Trans . Mathematical Software, 30(4):434-453, 2004. 



